Database context - Run server level statements on the connection - #10580

Type of Change

• Bug fix (non-breaking change, fixes Database-scoped SMO calls silently change the current database of the shared connection #10555 in part)
• Ran manual Pester test and has passed
• Pester test is included

Purpose

Step two of #10555, and the half that needs no new mechanism, so it is independent of #10579.

Ten call sites went through a database object only because they needed somewhere to run a statement. The execution manager of an SMO database is the connection context of the parent server, so each of them issued a USE and left the connection of the caller in master or msdb. None of the statements needed a database context at all.

The clearest example is Export-DbaLogin.ps1:391-393, where the primary path was already right and only the fallback was not:

$hashedPass = $server.ConnectionContext.ExecuteScalar($sql)          # fine
} catch {
    $hashedPassDt = $server.Databases['master'].ExecuteWithResults($sql)   # same query, leaks

Approach

Each statement now runs on the connection itself, so there is no context to put back:

Only the last one changes a statement. Verified that the three part name works and leaves the context alone:

context before : master
3-part sp_delete_job: worked
context after  : master
job still there: False

Also verified that ConnectionContext.ExecuteNonQuery takes the string array Set-DbaTempDbConfig hands it, which is the one signature difference between the two receivers.

The help of Connect-DbaInstance recommended the pattern this removes:

To execute SQL commands directly: $server.ConnectionContext.ExecuteReader($sql) or $server.Databases['master'].ExecuteNonQuery($sql)

It now points at the connection context and says why.

Tests

Regression contexts for the two sites that a test can actually reach, both asserting on a -NonPooledConnection, because SMO reopens a pooled one at its default database and hides the leak:

• Remove-DbaAgentJob still removes the job and leaves the connection where it was
• Get-DbaDbDetachedFileInfo still reads the file and resolves the collation, and leaves a connection that was on msdb on msdb

The other sites have no reachable test, and it is worth being explicit about why rather than adding a test that proves nothing:

• the three password hash sites are catch fallbacks for ExecuteScalar, which does not fail on a supported SQL Server, so the changed line does not run
• Get-OfflineSqlFileStructure has no callers anywhere in the module; the change is correct but the function is dead code
• Set-DbaTempDbConfig reaches its changed line only by really reconfiguring tempdb. The existing Set-DbaTempDbConfig tests do execute that path, so it is exercised, but a context assertion cannot pass yet - see below.

Test files run: Export-DbaLogin (20), New-DbaLogin (15), Get-DbaDbDetachedFileInfo (9), Remove-DbaAgentJob (12 + 1 skipped), Sync-DbaLoginPassword (9), all passing.

Set-DbaTempDbConfig is only half fixed by this

It also reads tempdb through $server.Databases['tempdb'].Query(...) in three places, which is the script method fix in #10579. Measured on this branch, the connection still ends up in tempdb from those calls even when the command stops before the line changed here:

context before : msdb
command failed: Current tempdb ... is not suitable to be reconfigured ...
context after  : tempdb

So the command is free of the leak only once both changes are in, and a context test for it belongs with the second one.

🤖 Generated with Claude Code